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Abstract:  The  Joint  Advanced  Distributed  Simulation  (JADS)  Joint  Test  Force  (JTF)  is  chartered 
by  Office  of  the  Secretary  of  Defense  to  investigate  the  utility  of  Advanced  Distributed  Simulation 
(ADS)  Technology  to  Test  and  Evaluation  (T&E).  JADS  is  executing  three  test  programs  (  C4I, 
Precision  Guided  Munitions,  and  Electronic  Warfare)  representing  slices  of  the  overall  T&E 
spectrum  as  well  as  observing  other  activity  within  the  T&E  community  to  form  its  conclusions. 

One  of  the  slices,  the  Electronic  Warfare  test,  is  using  HLA.  This  paper  discusses  process  and 
products  used  by  JADS  to  identify  system  requirements,  including  the  requirements  allocated  to 
the  RTI,  and  communicate  those  RTI  requirements  to  DMSO. 

1.  Introduction 

Building  a  federation  is  an  application  of  a  system  engineering  process  to  achieve  the  users  objective.  One  of 
the  cornerstones  of  system  engineering  is  the  ability  to  allocate  system  requirements  down  to  components. 
Another  requirement  is  to  be  able  to  articulate  component  requirements  to  suppliers.  The  focus  of  this  paper  is 
the  process  JADS  used  to  allocate  system  requirements  to  the  RTI  and  how  those  requirements  were  articulated 
to  DMSO.  This  is  the  companion  paper  to  98S-SIW-152  which  discusses  how  JADS  intends  to  verify  RTI  and 
network  performance. 


2.  Background 

JADS  is  an  OSD  sponsored  Joint  Test  Force  chartered  to  determine  the  utility  of  Advanced  Distributed 
Simulation  (ADS)  technology  for  Test  and  Evaluation  (T&E)  of  military  systems.  JADS  is  doing  this  by  looking 
at  three  slices  of  the  T&E  spectrum.  One  of  those  slices  is  the  JADS  EW  Self  Protection  Jammer  test.  This  test 
will  use  two  HLA  compliant  federations  to  recreate  an  actual  Open  Air  Range  (OAR)  test  to  see  how  the  results 
using  the  federations  correlate  with  the  OAR  results. 

The  OAR  test  represents  an  effectiveness  test  of  an  airborne  self  protection  jammer.  One  referent  test  condition 
will  be  repeated  to  gather  a  large  sample  of  jammer  effectiveness  data.  The  environment,  the  threat  systems, 
and  the  jammer  are  all  instrumented  to  allow  standard  measures  of  performance  to  be  calculated  and  to  allow 
the  engagements  to  be  recreated  in  the  federations.  Each  OAR  test  event  will  be  recreated,  the  federate 
interactions  will  be  monitored,  and  the  measures  of  performance  will  be  calculated  in  real-time 

3.  Requirements  Definition  Process 

The  requirements  definition  process  that  we  used  came  from  a  solid  understanding  of  the  interactions  between 
aircraft  carrying  self  protection  jammers  and  surface  to  air  threat  systems.  The  process  was  also  driven  by  a  lack 
of  understanding  of  object  oriented  design  methods  and  a  lack  of  understanding  of  the  functionality  and 
performance  the  RTI  could  bring  to  the  simulation.  The  problem  space  was  defined  by  the  referent  test 


condition  used  in  the  OAR  test.  As  the  referent  test  condition  was  refined,  the  problem  space  had  to  be 
reviewed  to  verify  that  the  federation  design  was  still  valid. 

The  top  level  design  was  accomplished  during  a  test  concept  review.  The  participants  took  the  test  concept  and 
identified  all  the  relevant  objects  that  appeared  in  the  scenario.  In  this  case,  objects  were  easy  to  identify  since 
there  are  only  a  few  physical  entities  that  interact  in  the  test  scenario.  The  result  was  a  fairly  flat  class  structure. 
The  participants  also  identified  all  the  attributes  of  interest  and  all  the  interactions  between  objects.  This  initial 
work  was  then  placed  on  hold  while  the  referent  test  condition  was  refined. 

The  next  phase  of  the  design  focused  on  the  interactions  and  on  the  work  previously  accomplished  by  the 
Engineering  Protofederation  (EPF).  Two  of  the  facilities,  ACETEF  and  AFEWES,  used  in  the  EPF  are  being  used 
in  the  JADS  federation.  Our  intent  was  to  sensibly  capture  pertinent  attributes  and  interaction  definitions  and 
message  structures  used  by  the  EPF.  This  represented  the  maximum  reuse  that  we  could  expect  and  allowed  us 
to  use  the  EPF  facility  interfaces  as  starting  points  for  designing  the  interfaces  for  JADS.  This  phase  of  the 
design  was  accomplished  over  three  technical  interchange  meetings.  The  result  was  a  spreadsheet  that  listed  all 
the  objects,  their  attributes,  and  their  interactions.  Structured  attributes  were  created  where  they  made  sense. 
Definitions  were  created  or  identified  from  DIS  to  ensure  the  team  understood  what  each  attribute  and 
interaction  meant.  The  spreadsheet  also  identified  the  number  of  bits  allocated  to  each  attribute  and  interaction 
and  the  frequency  each  needed  to  be  updated.  The  spreadsheet  became  our  conceptual  model  of  the  federation. 

The  third  phase  focused  on  determining  how  much  latency  the  jammer/  threat  interaction  could  tolerate  and 
still  be  valid.  There  are  two  valid  interactions  that  can  be  modeled,  each  requiring  a  different  latency.  The  first 
is  the  jammer  computer  to  threat  computer.  The  second  is  the  jammer  computer  to  human  operator.  The 
latency  is  driven  by  the  decision  cycle  times  of  the  jammer  computer  and  either  the  threat  computer  or  the  threat 
operator.  The  jammer  used  in  the  JADS  test  is  simple  and  has  a  very  short  decision  cycle.  Likewise  the  threat 
computers  have  very  short  decision  cycles.  The  analysis  showed  that  it  was  unrealistic  to  model  the  computer  to 
computer  interaction.  The  latency  expected  from  linking  AFEWES  in  Ft  Worth  TX  and  ACETEF  in  Patuxant 
River,  MD  was  too  great  to  faithfully  reproduce  the  engagements  that  normally  occur  at  distances  shorter  than 
50  km.  In  fact,  the  analysis  indicated  that  once  the  widearea  communications  time,  the  local  area  network 
communications  time,  and  the  facility  interface  processing  times  for  both  AFEWES  and  ACETEF  were 
accounted  for,  the  acceptable  latency  for  the  RTI  had  to  be  negative.  We  dropped  the  computer  to  computer 
interaction  and  opted  for  the  second  approach.  The  decision  cycle  time  for  the  threat  operator  was  estimated  to 
be  500  ms,  an  achievable  latency  objective.  Once  the  total  latency  was  identified,  the  500  ms  were  allocated  to 
the  communications  infrastructure,  facility  interfaces  and  the  RTI. 

The  latest  review  of  the  requirements  occurred  in  October  when  the  results  of  the  first  OAR  practice  mission 
were  reviewed  and  adjustments  made  to  the  conceptual  model.  The  conceptual  model  has  been  used  to 
generate  the  Federation  Object  Model,  determine  and  adjust  the  network  topology,  and  fill  out  the  DMSO 
Federation  Planner's  Workbook.  Figure  1  is  an  excerpt  from  the  conceptual  model  listing  the  key  assumptions. 
This  is  provided  to  give  the  reader  a  feeling  for  the  problem  space  JADS  is  examining. 


#  of  Threats 

4 

#  of  Targets 

1 

Run  Duration  (Single  test  event) 

600 

sec 

#  of  Technique  Assigns/run/  threat 

10 

#  of  Threat  Mode 

Changes  /  run/  threat 

10 

#  of  Simultaneous  RF  Signals 

20 

#  of  Signals  Tracked  by  SUT 

12 

SUT  Instrumentation  Reporting  Rate 

5 

Hz 

Network  Health  Check  Update  Rate 

1 

Hz 

TSPI  Update  Rate 

20 

Hz 

Tracking  Data  Update  Rate 
C3  Track  Update  Rate 

#  of  extraneous  RF  Changes/ run 

#  of  Missiles/ run/ threat 

#  of  Missiles  in  the  Air 

#  of  semi-active  Missiles  in  the  Air 

Figure  1  Key  Design  Assumptions 

4.  Allocation  of  Requirements 

The  following  is  a  summary  of  the  requirements  derived  for  the  JADS  EW  test.  These  requirements  are  only  for 
the  JADS  EW  test  and  in  no  way  represent  the  requirements  of  other  performance  based  federations  or  the 
requirements  for  Test  and  Evaluation  sponsored  federations. 


20  Hz 
1  Hz 
10 
20 
6 
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Performance  Measure 

JADS  Requirement 

Attribute/  interaction 
Size 

Max:  672  bits 

Min:  16  Bits 

Update  Frequency 

Max:  20  Hz 

Min:  1  Hz 

Expected  bandwidth 

Max:  183335  bits  per 
second 

Time  to  Create  New 
Objects 

10  milliseconds 

CPU  Utilization 

RTI:  25% 

Overhead:  5% 

Allowable  RTI  latency 

<  300  milliseconds 
for  closed  loop 
interaction 

Figure  2  Summary  of  RTI  Requirments 


5.  Communication  of  Requirements  to  RTI  Developers 

The  primary  tool  for  communicating  requirements  to  the  RTI  development  community  is  the  Federation 
Planner's  Workbook.  JADS  began  working  with  DMSO  to  articulate  our  perceived  requirements  for  RTI 
performance  in  May  97.  I  use  the  term  perceived,  because,  while  we  could  articulate  what  performance  we 
wanted  out  of  the  federation,  we  weren't  sure  what  aspects  of  performance  were  critical  from  an  RTI  builders 
perspective.  Our  first  attempt  was  to  create  a  system  specification  to  describe  RTI/network  performance. 
DMSO's  counterproposal  was  to  use  the  first  generation  of  RTI  performance  workbooks  which  were  Excel 
spreadsheets  being  designed  for  users  of  federations  to  communicate  different  aspects  of  RTI  performance 
requirements.  We  completed  these  and  have  subsequently  worked  through  two  other  versions  of  DMSO  tools. 
The  latest  version  are  the  Federation  Planners  Workbook. 

While  it  remains  to  be  seen  how  well  the  tools  facilitate  the  communication  between  RTI  developers  and 
federation  developers,  we  have  found  the  tools  to  be  extremely  useful  in  creating  the  JADS  EW  Federation 
Object  Model.  We  constantly  refered  to  the  Federation  Planner's  Workbook,  our  own  concept  model 
spreadsheets,  and  our  interface  control  document.  The  FOM  development  became  another  cross  check  of  the 
different  design  representations  prior  to  federate  development  and  integration. 


6.  Conclusion 


Throughout  the  process  of  developing  and  articulating  our  requirements,  we  have  raised  questions  and 
provided  comments  to  improve  not  only  the  product  but  the  level  of  understanding  on  both  the  RTI  developer's 
and  on  the  federation  developer's  sides.  There  is  still  work  that  needs  to  be  done.  For  example,  one  of  the 
critical  aspects  of  RTI  performance  seems  to  be  the  amount  of  computing  resources  available  for  it  to  use.  Yet 
articulating  this  requires  the  developer  to  quantify  the  tick  rate  without  necessarily  understanding  the  timing 
implications  to  the  simulation  and  to  overall  performance  of  the  federate. 

One  final  caution.  The  performance  that  JADS  has  identified  for  our  federation  should  not  be  interpreted  to  be 
the  level  of  performance  that  future  test  efforts  will  require.  The  purpose  of  JADS  is  to  determine  the  utility  of 
ADS  technology  for  Test  and  Evaluation.  Our  intent  was  to  approach  reasonably  close  to  edge  of  the 
performance  envelope  of  ADS.  The  CROSSBOW  sponsored  Threat  Simulator  Linking  Activity  developed  a 
network  specification  addressing  the  requirements  for  future  ADS  based  EW  testing  and  concluded  that  the 
tolerable  latency  for  operating  mode  data  (changes  in  either  threat  radar  or  jammer  state)  is  50  to  100 
milliseconds  with  a  goal  of  3  milliseconds.  As  we  try  to  develop  such  closely  coupled  systems,  we  will  need  to 
find  ways  for  developers  to  unambiguously  articulate  system  performance  requirements  and  RTI  suppliers  to 
unambiguously  articulate  actual  system  performance.  These  two  issues  will  become  critical  as  we  migrate 
towards  commercial  and  custom  developed  RTIs. 


